At present, large volumes of data are delivered over the Internet network to client computing devices such as desktop and laptop computers and various handheld digital devices using a communication protocol called, the Hyper Text Transfer Protocol (HTTP). The HTTP protocol can be visualized as a protocol for interaction between a HTTP client (or simply called client in this document) that sends requests for data, and a HTTP server (or simply called server in this document) that supplies the data. The client, after sending the request, waits for the server's response, and then normally, upon receipt of data, delivers the data to the end user. In many cases, the client is implemented by a software component called a web-browser. The server is usually implemented by a software component called a web-server. However, it is possible to use HTTP protocol by other types of software components to create a HTTP client or a HTTP server for exchange of data over the Internet. The client uses a text string called a Uniform Resource Locater (URL) to identify the data being requested by the client.
Since it is often the case that the data corresponding to a specific URL remains constant for some period of time, the HTTP protocol provides a mechanism for making use of the data previously accessed from the server which may be cached locally by a client. Such methods are described in R. Fielding, J. Gettys, J. Mogul, H Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Request for Comments: 2616, Hypertext Transfer Protocol-HTTP/1.1,” Network Working Group, June 1999 (“Fielding”), which is hereby incorporated by reference herein.
Generally, the primary benefits of caching data by the client are reduction in the volume of data transmitted by the server to the client, and reduction in the time required for accessing the data by the client. When a client locally stores or caches a copy of the data corresponding to a URL, the next time the same client requests the data for the same URL, the client's copy of the data corresponding to the URL is considered to be “fresh” or “stale” depending on whether the client's cached copy still contains the valid data or not. If the client's cache does contain a valid copy of the requested data, the client's copy is considered to be “fresh”. On the other hand, if the client's cached copy no longer contains valid data corresponding to the URL, the client's copy is considered to be “stale. The HTTP protocol outlined in Fielding essentially relies on one of two metrics to determine if the copy of the content cached at the client is “stale” or “fresh”:                A. The protocol can rely on the server that supplies data (called origin-server) to explicitly provide the expiration time and/or date for the data.        B. The client uses heuristics based on metrics specified by the HTTP protocol (such as the Last-Modified time) to estimate a plausible expiration time/date.        
In Method A, the origin-server provides an explicit expiration time/date for the data corresponding to the URL. The client's caching mechanism maintains a database that maps each named data to its respective expiration time/date. Thus, each time the data is requested, the client's caching mechanism checks the database to see if the data is in the local cache of the client and if the expiration time/date has passed. If the expiration time/date has not passed then the request is fulfilled directly from the local cache and the origin server is not consulted. This technique or method is known as the “expiration” method of cache control.
Method B differs from Method A in that the origin-server does not explicitly specify an expiration time/date for each object, rather the caching mechanism associated with the client uses its own internal metrics to approximate an expiration date and time.
Method A is the preferred caching method, and also the more accurate of the two, but it is generally only effective as long as the server's expiration times are carefully chosen. Unfortunately, for a large and complex server with dynamic data, it is almost impossible to know a priori how much time will pass before a specific data will semantically change.
While Method B does not impose any requirements on server's administrators, it is not possible for this method to be perfectly accurate and, as a result, it may compromise semantic transparency.
In general, caching, as described in Fielding has two specific methods for reducing the volume of data transmission during the interaction between a client and a server:                I. Eliminate the need to send full requests, using an “expiration” mechanism (“Expiration Time Method”).        II. Eliminate the need to send full responses, using a “validation” mechanism based on last-modified time (“Last-Modified Time Method”).        
As described earlier, Method I relies on the origin-server to supply an explicit expiration time/date for the data. According to this method, if the requested data is found in the local cache of the client, and it has not expired, the client need not send the request to the server.
On the other hand, for using the Method II, the origin-server need not provide an expiration date for the data. With Method II, the client's caching mechanism checks its database for a cached version of the requested data. If a cached version is found, then a request is sent to the origin-server to send the data if and only if the requested content has been modified since the time the client cached the data. If the content has not been modified, then the server only sends a response header and thereby instructs the client to use the cached copy. However, if the data has been modified since the last access, the server sends the new data.
Neither of Method I or Method II deals with a situation in which the data has been specified as not being suitable for caching by the server (or administrator thereof). In some situations, it may be simpler or more beneficial for a server to identify all data as not being suitable for caching so that there is no need to calculate/estimate an expiration time/date or other reason. As such, there is a need for a way to allow caching of many types of data, including that which is ordinarily indicated as “no cache”.